home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / dfs / dfs-minutes-90feb.txt < prev    next >
Text File  |  1993-02-17  |  5KB  |  146 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Peter Honeyman/University of Michigan
  8.  
  9.  
  10.  
  11. SYNOPSIS
  12.  
  13. Trans- and inter-continental distributed file systems are upon us.  The
  14. consequences to the Internet of distributed file system protocol design
  15. and implementation decisions are sufficiently dire that we need to
  16. investigate whether the protocols being deployed are really suitable for
  17. use on the Internet.  There's some evidence that the opposite is true,
  18. e.g., some DFS protocols don't checksum their data, don't use reasonable
  19. MTUs, dont offer credible authentication or authorization services, dont
  20. attempt to avoid congestion, etc.
  21.  
  22. Accordingly, a working group on DFS has been formed by the IETF. The WG
  23. will attempt to define guidelines for ways that distributed file systems
  24. should make use of the network, and to consider whether any existing
  25. distributed file systems are appropriate candidates for Internet
  26. standardization.
  27.  
  28. The WG will also take a look at the various file system protocols to see
  29. whether they make data more vulnerable.  This is a problem that is
  30. especially severe for Internet users, and a place where the IETF may
  31. wish to exert some influence, both on vendor offerings and user
  32. expectations.
  33.  
  34. dfs-wg@citi.umich.edu is a mailing list for ongoing discussions of the
  35. WG; administrative matters, such as requests to be added or dropped from
  36. the list, should be addressed to dfs-wg-request@citi.umich.edu, not to
  37. the list as a whole.
  38.  
  39. MINUTES
  40.  
  41. The meeting was chaired by Peter Honeyman.  At the meeting, plans were
  42. made to meet the following objectives.
  43.  
  44. OBJECTIVE: Produce a document for implementors and administrators, in
  45. the style of the Hosts Requirements RFCs.
  46.  
  47. Issues to be addressed include recommendations to be followed when UDP
  48. is used as the transport layer.  Most of these recommendations come from
  49. experiences with TCP. The recommendations include:
  50.  
  51.    o the use of the transport-layer checksum;
  52.    o techniques for congestion avoidance;
  53.    o techniques for fragmentation avoidance;
  54.    o retransmission strategy based on measured round-trip times.
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. The group intends to identify other recommendations and to flesh out the
  64. details in time for a review at the next IETF meeting.
  65.  
  66. OBJECTIVE: Standard for Kerberos authentication for NFS.
  67.  
  68. Several groups have deployed or are preparing to deploy NFS integrated
  69. with Kerberos.  Among these are MIT, U Michigan, and Transarc, Inc..
  70. These groups will describe the protocols they now use for establishing
  71. and maintaining Kerberos credentials in an NFS session.  The intent is
  72. to agree on a common protocol, which will be described in an RFC.
  73.  
  74. Representatives from MIT, Michigan, and Transarc agreed to describe
  75. their protocols in the dfs-wg mailing list.  At the next meeting of the
  76. IETF, substantive differences between the protocols will be discussed.
  77.  
  78. OBJECTIVE: Establish the requirements for Internet-friendly DFS
  79. protocols.
  80.  
  81. DFS protocols that were developed for a LAN environment can behave
  82. abysmally on a WAN. A well designed DFS will balance its performance
  83. needs with those of other users and uses of the network.
  84.  
  85. Many of the issues concerning the design of DFS protocols depend on one
  86. another, or on advances in other areas under study by the IETF. A
  87. partial list of the areas in which recommendations can be made includes:
  88.  
  89.  
  90.    o Naming
  91.    o Data representation
  92.    o Type management
  93.    o Locking
  94.    o Impact of design choices:
  95.       -  Statelessness
  96.       -  Cache management
  97.       -  Choice of transport
  98.    o Use of MTU discovery
  99.    o Authentication and authorization
  100.    o Trusted vs.  untrusted client
  101.    o Time protocol
  102.    o User expectations
  103.  
  104.  
  105. The first task is to establish concrete goals to guide the WG in this
  106. area.
  107.  
  108. GOALS FOR NEXT IETF MEETING
  109.  
  110. ``Guidelines for DFS Administrators and Implementors'' in draft form.
  111. Current status of Kerberized NFS implementations on paper.  Further
  112. discussion on "Guidelines for DFS Designers."
  113.  
  114.  
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123. ATTENDEES
  124.  
  125. Richard Basch                         probe@mit.edu
  126. Dave Borman                           dab@cray.com
  127. Peter Honeyman                        honey@citi.umich.edu
  128. Mike Karels                           karels@berkeley.edu
  129. Ole Jacobsen                          ole@csli.stanford.edu
  130. Dan Jordt                             danj@washington.edu
  131. Loius A. Mamakos                      louie@trantor.umd.edu
  132. Tony Mason                            mason@transarc.com
  133. Matt Mathis                           mathis@pele.psc.edu
  134. Leo J. McLaughlin                     ljm@twg.com
  135. Greg Minshall                         minshall@kinetics.com
  136. Don Morris                            morris@ucar.edu
  137. Drew Perkins                          ddp@andrew.cmu.edu
  138. Joel Replogle                         replogle@ncsa.uiuc.edu
  139. Dean Throop                           throop@dg-rtp.dg.com
  140. A. Lee Wade                           wade@orion.arc.nasa.gov
  141. Dan Wintringham                       ydanw@osc.edu
  142.  
  143.  
  144.  
  145.                                    3
  146.